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DETAILED ACTION 

Response to Amendment 

This office action is responsive to the amendment filed on 05/15/2009. 
Claims 1, 2, 5-8, 10-13, and 16-23 have been amended. 
Claims 1-26 are pending in the Application. 

Claim Rejections - 35 USC § 102 

1. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

2. Claims 1-26 are rejected under 35 U.S.C. 102(b) as being anticipated by Hamiti et al (US 
6751209 Bl). 

Regarding claims 1, 12 and 13 , Hamiti discloses a method and a system to process the method of 
radio transmission of real-time IP packets using header compression, comprising: 

header-compressing a number of RTP packets, (fig. 1 : for each RTP packet 1 1 shown 
header compression is carried out) , to obtain header-compressed RTP packets having a plurality 
of different header compression lengths, (packet 16 with a plurality of different header 
compression lengths), wherein a single compressed header corresponds to a single RTP payload 
in each of the header-compressed RTP packets, (shown in the figure, element 16 each of the 
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containing separate header corresponds to an RTP payload: this corresponds to different 
compression values, col. 8 lines 41-42), 

pre-configuring header compression lengths and length types required by the system, 
(fig. 5, note the compressed RTP header: col. 7 lines 1-6: field 51 indicates the type T; 
correspondingly field 53 indicates the length), and 

PDU-size adapting the plurality of different header compression lengths of the header- 
compressed RTP packets, so as to comply with said lengths and length types required by the 
system, (col. 7 lines 1-6 indicates the lengths and length types for, if T=0, the last octet 56 is not 
included and the last six bits 53 of the first octet arc set to zero, used for some other purpose, e.g. 
for CRC check, or used for an abbreviated time-stamp. If T=l the compressed header shall 
include the length octet and the bits 53 and the last octet 56 are used to indicate the length of the 
RTP payload. Furthermore, fig. 5 field 56 represents the data block containing the compressed 
header: this corresponds a Packet Data Unit (PDU) contains an integral number of octets, a 
header part and a data part, col. 9 lines 50-54). 

Regarding claim 2 , Hamiti discloses marking a compressed header and an RTP payload, 
(The format of the compressed header follows the one presented in connection with fig. 5; thus 
as indicated, col. 7 lines 8-9: field 52 indicates the marker bit of the RTP header) and separating 
the compressed header from the RTP packet based on said marking before PDU-size adapting 
the header-compressed RTP packet, and then PDU-size adapting the separated compressed 
header, (as illustrated in fig. 3, considering the RTP, col. 5 lines 20-22, field 314 includes a 
marker bit that is optionally used to mark important events in the packet stream, for instance, the 
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beginning of a speech burst, or a last packet in a video frame. If the marker bit 3 14 is used it 
needs to be transmitted in the compressed header). 

Regarding claim 3 , Hamiti discloses after separating the compressed header from the 
RTP payload based on said marking, further dividing the RTP payload into blocks of different 
error sensitivities based on the RTP payload format information, then PDU-size adapting the 
separated compressed header, (col. 5 lines 20-22, field 314 includes a marker bit that is 
optionally used to mark important events in the packet stream, for instance, the beginning of a 
speech burst, or a last packet in a video frame). 

Regarding claims 4 and 15 , Hamiti discloses after dividing the RTP payload into blocks 
of different error sensitivities, combining the compressed header with at least one data blocks of 
the RTP payload, then PDU-size adapting the data blocks containing said compressed header, 
(col. 8 lines63-67 and col. 9 lines 1-14: a delay packet for a particular compression sequence 
(thus having a particular error sensitivity), may be combined with the payload for, a packet 
belonging to a compression sequence preceding the precedent compression sequence would not 
be regenerated correctly anymore and therefore such packets are preferentially managed already 
in the compressor. The flow chart of FIG. 7 presents an example of such a filtering algorithm 
that can be added to the invented method in the compressor side for managing situations with 
much delayed packets) 

Regarding claims 5 and 17 , Hamiti discloses applying a UEP mechanism to the separated 
compressed header and the RTP payload, or the separated compressed header and the data 
blocks of the RTP payload, or the data blocks containing the compressed header and the 
remaining RTP payload data blocks, (col. 5 lines 37-43: indicates unequal error protection 
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mechanism that applies to RTP packet: this field does not have to be transmitted over the 
transmission link that has a strong error protection mechanism or means to detect transmission 
errors (e.g. lower protocol layer checksums). Transmission of such information can be done 
using acknowledged mode or strong error protection). 

Regarding claim 6 , Hamiti discloses mapping the separated compressed header and the 
RTP payload, or the separated compressed header and the data blocks of the RTP payload, or 
the data blocks containing the compressed header and the remaining RTP payload data blocks to 
different RLC entities for transmission, (fig. 1 divided into an appropriate number of RLC blocks 
each containing a separate header) 

Regarding claims 7 and 18 , Hamiti discloses transmitting the compressed header and the 
RTP payload, or the separated compressed header and the data blocks of the RTP payload, or 
the data blocks containing the compressed header and the remaining RTP payload data blocks 
on the same transmission time interval, and configuring corresponding transport channels 
thereof as "coordinated dedicated transport channels, (In accordance with its program, the 
microprocessor uses the RF block 103 for transmitting and receiving messages on the radio path, 
(a dedicated channel)) 

Regarding claim 8 , Hamiti discloses receiving and extracting, at a receiving end, the 
compressed header and the RTP payload, or the separated compressed header and the data 
blocks of the RTP payload, or the data blocks containing the compressed header and the 
remaining RTP payload data blocks, from RLC entity SDU corresponding to the compressed 
header and the RTP payload, or the separated compressed header and the data blocks of the 
RTP payload, or the data blocks containing the compressed header and the remaining RTP 
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payload data blocks, respectively, (fig. 9: the compressed packet is received at the decompressor 
(step 92), when changes are detected, a new SNDCP functionality will extract from the new 
header only the changed no-change fields (step 96), update them to the stored state of 
compression (step 97), transmit said values to the SGSN (step 98) and update the values to the 
state of compression stored in the SGSN as well (step 98). 

Regarding claim 9 , Hamiti discloses combining the extracted compressed header and the 
RTP payload, or the separated compressed header and the data blocks of the RTP payload, or 
the data blocks containing the compressed header and the remaining RTP payload data blocks, 
into a complete RTP packet, (step 96 fig. 9, doing the extraction. Note fig. 1 that number of RLC 
blocks each containing a separate header) 

Regarding claim 10 , Hamiti discloses the lengths and length types required by the system 
depend on a tradeoff between transmission efficiency and TFCI decoding reliability, (fig. 5. note 
the TFCI is transferred across the air interface and allows the receiving layers to identify the 
current valid Transport Format Combination, thus as shown in fig. 3, col. 5 lines 12-16, field 315 
indicates the payload type and is constant for one type of data. Generally, the contributing source 
and synchronization source are constant throughout the transmission over the air interface, and 
therefore the field 318 will remain constant) 

Regarding claims 1 1 and 19 , Hamiti discloses the RLC entity is a TM mode RLC entity, 

(fig- 5). 

Regarding claim 14 , Hamiti discloses after separating the compressed header from the 
RTP payload, PDU-size adapting the compressed header, such that the plurality of different 
header compression lengths obtained when header- compressing the RTP packet are adapted to 
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lengths and length types required by the system, and then making the PDU-size-adapted 
compressed header and the RTP payload to respectively form PDCP layer PDUs before 
mapping them into different PLC entities, (fig. 5 field 56 represents the data block containing the 
compressed header: this corresponds a Packet Data Unit (PDU) contains an integral number of 
octets, a header part and a data part, col. 9 lines 50-54). 

Regarding claim 16 , Hamiti discloses combining the separated compressed header with at 
least one data blocks of the RTP payload, and PDU-size adapting the data blocks containing said 
compressed header, (fig. 5 field 56 represents the data block containing the compressed header: 
this corresponds a Packet Data Unit (PDU) contains an integral number of octets, a header part 
and a data part, col. 9 lines 50-54). 

Regarding claim 20 , Hamiti discloses a method of receiving real-time IP packets using 
header compression, wherein a compressed header of the header-compressed packet, (shown in 
the figure, element 16 each of the containing separate header corresponds to an RTP payload: 
this corresponds to different compression values, col. 8 lines 41-42), 

is separated from an RTP payload thereof at the transmitting end to form different 
PDCP layer PDUs that are transmitted on different RLC entities, and wherein a single 
compressed header corresponds to a single RTP payload in each of the header-compressed RTP 
packets, said method comprising: 

receiving and extracting the compressed header and the RTP payload from SDUs of the 
RLC entities, (fig. 9: the compressed packet is received at the decompressor (step 92), when 
changes are detected, a new SNDCP functionality will extract from the new header only the 
changed no-change fields (step 96), update them to the stored state of compression (step 97), 
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transmit said values to the SGSN (step 98) and update the values to the state of compression 
stored in the SGSN as well (step 98), and 

combining the extracted compressed header with the RTP payload, (col. 8 lines63-67 and 
col. 9 lines 1-14: a delay packet for a particular compression sequence (thus having a particular 
error sensitivity), may be combined with the payload for, a packet belonging to a compression 
sequence preceding the precedent compression sequence would not be regenerated correctly 
anymore and therefore such packets are preferentially managed already in the compressor. The 
flow chart of FIG. 7 presents an example of such a filtering algorithm that can be added to the 
invented method in the compressor side for managing situations with much delayed packets) 

Regarding claim 21 . Hamiti discloses a system of transmitting a real-time IP packet using 
header compression, comprising: 

a header compression unit to header-compress RTP packets and mark a compressed 
header and an RTP payload, (The format of the compressed header follows the one presented in 
connection with fig. 5; thus as indicated, col. 7 lines 8-9: field 52 indicates the marker bit of the 
RTP header), wherein a single compressed header corresponds to a single RTP payload in each 
of the header-compressed RTP packets, (shown in the figure, element 16 each of the containing 
separate header corresponds to an RTP payload: this corresponds to different compression 
values, col. 8 lines 41-42), 

a radio link adaptation unit to separate the compressed header from the RTP payload 
based on said marking, to respectively form PDCP layer PDUs before mapping the respective 
PDCP layer PDUs to different RLC entities, and a transmitter to transmit the separated 
compressed header and RTP payload, (fig. 3, considering the RTP, col. 5 lines 20-22, field 314 
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includes a marker bit that is optionally used to mark important events in the packet stream, for 
instance, the beginning of a speech burst, or a last packet in a video frame. If the marker bit 3 14 
is used it needs to be transmitted in the compressed header; furthermore, col. 4 lines 58-64, the 
access network SNDC function provides to the network layer a service for transferring a 
minimum amount of data between the SGSN and MS , (transmitters) through different 
compression techniques. 

Regarding claim 22 , Hamiti discloses a system of receiving a real-time IP packet using 
header compression, (fig. 10 and col. 12 lines 33-55: a mobile terminal of a mobile 
communication equipment), wherein a compressed header of the header-compressed packet is 
separated from an RTP payload thereof at the transmitting end to form different PDCP layer 
PDUs that are transmitted on different RLC entities, wherein a single compressed header 
corresponds to a single RTP payload in each of the header-compressed RTP packets, (shown in 
the figure, element 16 each of the containing separate header corresponds to an RTP payload: 
this corresponds to different compression values, col. 8 lines 41-42), said system comprising: 

receiving and extracting unit for to receive and extract the compressed header and the 
RTP payload from SDUs of the RLC entities, (fig. 9: the compressed packet is received at the 
decompressor (step 92), when changes are detected, a new SNDCP functionality will extract 
from the new header only the changed no-change fields (step 96), update them to the stored state 
of compression (step 97), transmit said values to the SGSN (step 98) and update the values to the 
state of compression stored in the SGSN as well (step 98), and 
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radio link adaptation unit for combining the extracted compressed header with the RTP 
payload, (col. 12 lines 33-55:the microprocessor uses the RF block 103 for transmitting and 
receiving messages on the radio path.) 

Regarding claim 23 , Hamiti discloses an RTCP packet scheduling method, comprising: 
monitoring whether or not the bandwidth requirement of the RTP packet exceeds a 
predetermined value, (col. 7 lines 31-65), if the bandwidth requirement of the RTP packet 
exceeds the predetermined value and there is an RTCP packet to be transmitted, (col. 7 lines 31- 
65), buffering the RTCP packet, (col. 4 lines 64-66, a number of the header data fields that 
remain constant during the data transfer being stored in the decompressor), and continuously 
monitoring the bandwidth requirement of the RTP packet, and transmitting the RTCP packet 
when the bandwidth requirement is lower than the predetermined value, (col. 9 lines 15-37: no 
packet transmitted due to delay conditions, the packet is deemed useless). 

Regarding claim 24 , Hamiti discloses the bandwidth requirement being lower than the 
predetermined value comprises the case where the compression rate of the RTP packet is so high 
that the bandwidth requirement is lower than the predetermined value, (col. 7 lines 66-67 and 
col.8 lines 1-30). 

Regarding claim 25 , Hamiti discloses the bandwidth requirement being lower than the 
predetermined value comprises the case where no RTP packet is transmitted, (col. 9 lines 15-37: 
no packet transmitted due to delay conditions, the packet is deemed useless) 

Regarding claim 26 , Hamiti discloses an RTCP packet scheduling system, comprising: 
bandwidth monitoring means for monitoring whether or not the bandwidth requirement of the 
RTP packet exceeds a predetermined value, (col. 7 lines 31-65), judging means for judging, 
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whether the bandwidth requirement of the RTP packet exceeds the predetermined value and 
there is an RTCP packet to be transmitted, (col. 7 lines 31-65), buffering means for buffering the 
RTCP packet, in response to the result of the judging means that the bandwidth requirement of 
the RTP packet exceeds the predetermined value, (col. 4 lines 64-66, a number of the header data 
fields that remain constant during the data transfer being stored in the decompressor); and 
transmitting means for transmitting the RTCP packet, in response to the result of the judging 
means that the bandwidth requirement of the RTP packet does not exceed the predetermined 
value, (col. 9 lines 15-37: no packet transmitted due to delay conditions, the packet is deemed 
useless). 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to EMMANUEL MAGLO whose telephone number is (571)270- 
1854. The examiner can normally be reached on Monday - Thursday 7:00 - 4:30 and every other 
Friday 7:00 -3:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, William Trost can be reached on (571)272-7872. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

Emmanuel Maglo 
Patent Examiner 
August 31, 2009 



/William Trost/ 

Supervisory Patent Examiner, Art Unit 2416 



